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Writing X.400 O/R Names 
Status of this Memo 


This memo provides information for the Internet Community. It does 
not specify an Internet Standard of any kind. Distribution of this 
memo is unlimited. 


1. Introduction 


There is a need for human beings who use X.400 systems to be able to 
write down O/R names in a uniform way. 


There has been a preexisting recommendation on how to write O/R names 
for human consumption in the RARE community. Now that the ISO/ITU has 
adopted a recommendation on how to do this [1], RARE needs to update 
its recommendation on writing O/R names to take this standard into 
account. 


2. Recommendations on writing O/R names 
RARE recommends that the ISO standard be followed when writing O/R 
names. The ISO/ITU standard contains a number of options. RARE makes 


the following recommendations: 


a The "main" abbreviations, G, I, S, O, OU1, OU2, P, A and C 
are used. They should be written using UPPER CASE. 


= The separation character should be semicolon (;). 
E The ADMD value "blank" is expressed by omitting the 


attribute. No other interpretation of a missing ADMD 
attribute is allowed. 


- The recommended sequence is G=; I=; S=; O=; OU1=; OU2=; P=; A=; C=; 


This means that the O, OU1 and so on will be in opposite order to the 
fields of an Internet domain name; the reason for choosing the 
ISO/ITU order is that this will be more common among users of X.400 
services. 
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3. Copy of the recommmendation 


This is a COPY of a DRAFT of the relevant appendix. For the 
authoritative text, consult the ITU standard itself. 


Final text for AMENDMENT, 7 February 1993 
Annex to CCITT Rec. F.401 and ISO/IEC 10021-2/Am.1 
Annex F 


Representation of O/R addresses for human usage (This annex does 
not form an integral part of this Recommendation | International 
Standard) 


F.1 Purpose 


An O/R address (specified in clause 18) consists of a set of 
values of attributes taken from the list shown in Table F.1. In 
order to represent visually an address to a human user, and to 
enable the user to enter the address into a user interface, each 
attribute value needs to be associated with the correct attribute 
type. Many of the names of the attribute types shown in Table F.1 
are too long for convenient usage on paper or a screen. There is a 
need for a format which allows attributes to be represented 
concisely, e.g., on a business card. 


This annex specifies how addresses can be expressed concisely 
using labels to represent the attribute types. There are three 
categories of attributes: those standard mnemonic attributes which 
are most likely to be found in O/R addresses represented for human 
usage (e.g., on business cards), those used in physical delivery 
addresses, and other specialised attributes (including domain 
defined attributes). In order to provide a format which is as 
concise as possible, many of the labels are single characters. 
This also makes them less language dependent. 


Clause F.3 specifies the format for the representation of 
addresses, and clause F.4 specifies the characteristics necessary 
for user interfaces which are intended to be used in conjunction 
with this format. 


F.2 Scope 


A labelled format for the communication of O/R addresses to human 
users is specified. The format consists of a set of pairs of 
labels and attribute-values. The characteristics of a user 
interface which are necessary to accept addresses given in this 
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format are also specified. 


In addition a self-explanatory format suitable for use where there 
is more space, e.g., in printed material and in the user 
interface, is specified. 


F.3 Format 
F.3.1 General 


The objective of the labelled format is to enable O/R addresses to 
be represented in a format which is concise and which can be 
accurately transcribed by human users. This can be facilitated by 
careful consideration of which attributes and values are used to 
form an O/R address. 


If the attributes of an O/R address include characters from an 
extended character set, human users who do not normally use the 
same extended character set may have difficulty representing the 
O/R address or entering it into their messaging system. In this 
situation, an alias of the O/R address should be provided which is 
composed entirely of printable string characters. 


NOTES 


ike The policy for structuring O/R addresses needs to be 
carefully considered. Individual O/R addresses should be 
allocated within an appropriate division of the address 
space to reduce to an acceptable level the probability that 
2 users might expect to have the same O/R address. Use of 
given name or initials is usually sufficient to distinguish 
between users. It may be inappropriate to reflect too much 
granularity in OUs particularly if the organizational 
structure is subject to frequent change, or users move 
between OUs. 


23 There may be a conflict between the benefits of using long 
values for attributes which are self explanatory (such as 
the full name of an organisation) and the benefits of 
shorter values (e.g., to concisely fit on a business card). 
One solution to this problem is to provide an alternative 
short attribute value (such as the initials of the 
organisation) as an alias for the long value. 


3. If a human user might be uncertain about the existence of a 
space in an attribute value (particularly when it is 
typeset), aliases could be provided with and without the 
space (e.g., "SNOMATL400" as an alias for "SNOMAIL 400" and 
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"Mac Donald" as an alias for MacDonald). 


4, If an alias is provided for an O/R address, it is desirable 
that this is implemented in such a way that a consistent 
(preferred) form of O/R address is generated for all 
messages originated by the user. 


Where national usage permits a single space value for the ADMD in 
an address, this is represented in the address either by omitting 
the ADMD attribute, or showing the ADMD attribute with no value or 
the value of a space. 


F.3.2 Labelled format 
F.3.2.1 Syntax 


O/R addresses in labelled format consist of delimited pairs of 
labels and values in the syntax <label>"="<value>. The labels for 
each attribute are specified in Tables F.1, F.2 and F.3. (The 
physical delivery attributes in Table F.2 are included for 
completeness.) The label and its value are either separated by the 
character "=", or by the space between two columns in a table. 
Labels may be represented in upper or lower case, but the use of 
uppercase is recommended as it is likely to be more visually 
distinctive. 


If label/value pairs appear in sequence on a line, they are 
separated by delimiters. Delimiters may optionally be followed by 
one or more spaces. The delimiter character may be either ";" or 
"/", but only one of these can be used in one O/R address. When 
the delimiter is "/" the first label is prefixed by "/". The use 
of a delimiter at the end of a line is optional. If the value of 
any attribute contains the delimiter character, this is 
represented by a pair of delimiter characters. 


If an identifier is required to preface a labelled address, it is 
recommended that "X.400" is used. 


If an address is entirely composed of attributes contained in 
Table F.1, it is recommended that the sequence of attributes in 
the address is that given in Table F.1. If this sequence is 
incompatible with normal cultural conventions, an alternative 
sequence may be adopted for representations of addresses which are 
primarily intended for use within that culture. 
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EXAMPLE 
X.400: G=john; S=smith; O=a bank ltd; P=abl; A=snomail; C=aq 


This address may also be layed out as a table: 


G John 

S Smith 

O A Bank Ltd 
P ABL 

A Snomail 

C AQ 


Table F.1. Standard Attributes of the Mnemonic Address Form 


Attribute Type Abbreviation Label 
(where necessary) 


Given Name Given name G 
Initial Initials I 
Surname Surname S 
Generation Qualifier Generation Q 
Common Name Common Name CN 
Organization Organization O 
Organizational Unit 1 Org.Unit.1 OU1 
Organizational Unit 2 Org.Unit.2 OU2 
Organizational Unit 3 Org.Unit.3 OU3 
Organizational Unit 4 Org.Unit.4 ou4 
Private Management Domain Name PRMD P 
Administration Management Domain Name ADMD A 
Country Country C 
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Physical Delivery Personal Name PD-person PD-PN 
Extension of Postal O/R Address 
Components PD-ext.address PD-EA 
Extension of Physical Delivery Address 
Components PD-ext.delivery PD-ED 
Physical Delivery Office Number PD-office number PD-OFN 
Physical Delivery Office Name PD-office PD-OF 
Physical Delivery Organization Name PD-organization PD-O 
Street Address PD-street PD-S 
Unformatted Postal Address PD-address PD-Al 
PD-A2 
(there are individual labels for PD-A3 
each line of the address) PD-A4 
PD-A5 
PD-A6 
Unique Postal Name PD-unique PD-U 
Local Postal Attributes PD-local PD-L 
Postal Restante Address PD-restante PD-R 
Post Office Box Address PD-box PD-B 
Postal Code PD-code PD-PC 
Physical Delivery Service Name PD-service PD-SN 
Physical Delivery Country Name PD-country PD-C 
Table F.3. Other Attributes 
X.121 Network Address M21 Xs T21 
E.163/E.164 Network Address ISDN ISDN 
PSAP Network Address PSAP PSAP 
User Agent Numeric ID N-ID N-ID 
Terminal Identifier T-ID T=ID 
Terminal Type T-TY T-TY 


Domain Defined Attribute 
DDA: <type> 


DDA: <type> 


where the notation <type> identifies the type of domain defined 
attribute. 


F.3.2.2 Terminal Type 


There are currently six terminal types, and if international 
consistency is required the following specific abbreviations 
should be used to represent the values for these types: tlx, ttx, 
g3fax, g4fax, ia5 and vtx. 
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F.3.2.3 Domain Defined Attribute 


The label for a DDA consists of "DDA:" followed by the DDA type. 
If an address includes more than one DDA of the same type, it is 
assumed that the DDAs are intended to be processed in the sequence 
in which they are represented. 


EXAMPLE - DDA:RFC-822=fred(a)widget.co.uk; O=gateway; P=abc; C=gb 


If the <type> of a DDA type includes the character "=", it is 
represented by "==". 


F.3.3 Self-explanatory format 


The self-explanatory format may be used when space is available. 
It consists of a list of the attribute types, either in full or 
abbreviated. The attribute types or abbreviations may be in any 
language, but each attribute type or abbreviation in Table F.1 is 
followed by the specified label. If English language abbreviations 
are used, they should be those given in Tables F.1, F.2 and F.3. 


If an address is entirely composed of attributes contained in 
Table F.1, it is recommended that the sequence of attributes in 
the address is that given in Table F.1. If this sequence is 
incompatible with normal cultural conventions, an alternative 
sequence may be adopted for representations of addresses which are 
primarily intended for use within that culture. 


EXAMPLE 1 - Using attribute types in the Norwegian language 


Fornavn (G) Per 
Etternavn (S) Hansen 
Organisasjon (O) Teledir 
Organisasjonsenhet (OU1) Forskning 
Privat domene (P) Tele 
Administrasjonsdomene (A) Telemax 
Land (C) NO 
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EXAMPLE 2 - Using attribute types and abbreviations in the English 


language 
Given name (G) John 
Surname (S) Smith 
Organization (O) A Bank Ltd 
Org. Unit (OU1) IT Dept 
Org. Unit (OU2) MSG Group 
PRMD (P) ABL 
ADMD (A) Snomail 
Country (C) AQ 


F.4 User interface 


This clause specifies the characteristics of a user interface 
which are necessary to enable a user to input O/R addresses 
represented in either of the formats specified in clause F.3. 


It is necessary for the user interface to be able to accept any 
valid combination of attributes from Tables F.1, F.2 and F.3. 


If the user interface lists the attributes given in Table F.1, it 
is recommended that either the sequence used in Table F.1 should 
be used, or if this sequence is incompatible with normal cultural 
conventions, the alternative sequence adopted within a particular 
culture. 


If the user supplies a value for the PRMD attribute but omits the 
ADMD attribute, or omits the value for the ADMD attribute, the 
ADMD value to be used is a single space. 


Where an interface accepts an O/R address as a single string 
(e.g., in a command line interface), it is necessary to accept any 
valid labelled format address allowing the user to enter either 
delimiter. The interface should not require the attributes to be 
specified in any particular order. The interface should accept 
labels in upper or lower case. 


NOTE - For some existing command line interfaces it may be 
necessary to enclose the whole labelled format address in quotes. 


If any other type of interface is provided (e.g., a prompting or 
form-fill interface), it is necessary to provide a means which 
enables the user to easily associate the identity of each 
attribute with the labels specified in Tables F.1, F.2 and F.3. 
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NOTES 


Is One way to associate the identity of each attribute with the 
labels is to follow the attribute type (or abbreviation) for 
each attribute with the label in brackets, for example: 


Given name (G) 

Initials (I) 

Surname (S) 

Generation Qualifier (Q) 
Common Name (CN) 
Organization (0) 
Organizational Unit 
Organizational Unit 
Organizational Unit 
Organizational Unit 4 (0U4) 

Private Management Domain Name (P) 
Administration Management Domain Name (A) 
Country (C) 


w Ne 
O 
G 
N 


2s Many users may have difficulty copying an address presented 
as a table (either in labelled or self-explanatory format) 
into a command line interface which uses delimiters. 


3). For form-fill style interfaces, user performance will be 
optimised when the interface most closely resembles the 
format of the supplied address with the same sequence of 
attributes using the same attribute types or labels. 


Examples of application 


Les The Norwegian user of a command line interface receives a 
business card containing the following O/R address: 


G=john; S=smith; O=a bank ltd; P=abl; A=snomail; C=aq 


The command line interface enables the user to type in the 
address exactly as presented on the card. 


2. The Norwegian user of a form fill interface receives the 
same business card. The form on the screen includes the 
following field names: 
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Fornavn (G) 

Etternavn (S) 
Organisasjon (0) 

Privat domene (P) 
Administrasjonsdomene (A) 
Land (C) 


The user is able to fill in the form by associating the 
single letter labels on the business card with the same 
labels in brackets after the Norwegian names of the 
attributes on the screen. (For form fill input the 
delimiters are not used.) 


The English speaking user of a command line interface 
receives a document quoting the following O/R address: 


Fornavn (G) Per 
Etternavn (S) Hansen 
Organisasjon (0) Teledir 
Organisasjonsenhet (OU1) Forskning 
Privat domene (P) Tele 
Administrasjonsdomene (A) Telemax 
Land (C) NO 


The user knows how to transform the address from self- 


1994 


explanatory to labelled format. The user can choose to enter 


the address with either delimiter, e.g.,: 


g=per; s=hansen; o=teledir; oul=forskning; p=tele; a=telemax; c=no 


or: 


4. References 


[1] 


F.401 - CCITT Message Handling Services - Operations 
and Definitions of Service - Naming and Addressing 
for Public Message Handling Services, Annex B 
(08/92). 


Available (at the time of writing) as the GOPHER URL: 


gopher://info.itu.ch/9/.1/ITUdoc/.dirtree/.1/.itu- 
t/.rec/.f£/.23068/.7724.zip 


/g=per/s=hansen/o=teledir/oul=forskning/p=tele/a=telemax/c=no 
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5. Security Considerations 
Security issues are not discussed in this memo. 
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